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for Snare Date Systems frrnw ' or biting sprieeeraft are using the Consultative Committee 
^ a Systems (CCSDS) protocol for better optimization of down link RF bandwidth 

rnnti°n nb 0 /t rd k age Spa f* *?° wever ’ m ost of th e associated housekeeping data has 

1° be g £? erated and down linked m a synchronous, Time Division Multiplexed 
(TDM) fashion. There are many economies that the CCSDS protocol will allow to^etter 
utilize the available bandwidth and storage space in order to optimize the housekeeping data 
for use in operational trending and analysis work. By only outputting what is currently 
important or of interest, finer resolution of critical items can be obtained. This can be Y 

^ CC ^ pllshed by betl P' utd i z mg the normally allocated housekeeping data down link and 
storage aieas rather than taking space reserved for science. 


Background 

data from^teS^MPPYlm^i p Stl ! dy t0 optimiz ® the archival of spacecraft housekeeping 
ata trom the SAMPEX Small Explorer mission for use in long term data analvsis and* ^ 

trending needs. As the study progressed, it became apparent tha/manv of these 

? ti ^ lzatl . on tecbnic l ue s could be put into the spacecraft itself by taking advantage of new 

advances in flight certified microprocessors and the options provided by the CCSDS nrotorol 

Future missions could be programmed to detect most of the problems that the ground dam 

. ystems currently look for and provide for higher resolution data to help in troubleshooting 

when a problem arises, filtering out unnecessary data when the spacecraft health is nominfl. 

When health and safety data is processed and analyzed, some data that is storpH 
onboard in the recorder is filtered out on the ground and discarded As long as parameters 

unreres^arfother d'amif nTT Chang f’ this infoimatio " * redundant and 
unnecessary Other data is output synchronously at to slow a rate to be of anv use for 

anomaly analysis. This data may give indications of a problem, but not enough information m 

know exactly what is going on, or it may mask a problem for weeks or monfi everne 

due too period, c sampling of the data that may be asynchronous to brief anomalous evenS 

tu u ^ ?h°uld be noted that attitude determination was not addressed in this stuHv P V pn 
though attitude data is usually considered a subset of the housekee^g datf AtthuL Z 
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packetization algorithms should be specified so as to meet science data processing 
requirements rather than performance analysis requirements that are usually less stringent. 


Types of housekeeping data 

The housekeeping data for SAMPEX fell into one of six different general categories; 
discrete counters, digital status data, analog data, flight software memory dumps, flight 
software memory dwell data and science quicklook packets. Time was not included in this 
study as a separate category as it is a parameter in every CCSDS packet header and therefore 
usually is not a part of the application data field. Obviously, time must be transmitted in such 
a fashion as to know when each telemetered data value was sampled. 

The first category, discrete counters, is the primary means to monitor and diagnose the 
performance of flight software and/or the command and data handling unit. This data falls 
into two general subcategories. These are counters that infrequently increment and those 
which constantly increment. The counters that infrequently increment include command 
execution counters, command execution error counters and miscellaneous error counters. 
These types of counters are of interest only when they change value. The counters that 
constantly increment include time, task execution counters, and data storage accounting 
statistics. Some of these counters are always of interest, some are only of interest during 
flight software diagnostic testing, and some are only of interest during real-time. 

The second category, digital status data, consists of configuration data (items that can 
be modified by command), error flags, environmental flags (generally indicate some orbital 
characteristic such as day or night delimiters) and informational data. This data is generally 
supplementary data that helps to determine when something happened and, like the 
infrequently incrementing counters mentioned above, are of interest only when they change. 
Examples of this type of data include spacecraft event messages, calculated onboard table 
checksums, flight software load and dump information and error handler takeover reasons. 

The third category, analog telemetry, is probably the most important data for 
monitoring the health and safety of the spacecraft. What is key here is getting the right amount 
of data to detect problems or degradation without monopolizing the onboard data storage space 
or the down link bandwidth. 

The next two categories, flight software memory dumps and flight software memory 
dwell data, are generally used for flight software maintenance purposes and would probably 
only be output on receipt of a spacecraft command. Handling of this data is an entire subject 
in itself and is not specifically referenced in this paper. 

The last category, quicklook data, is generally handled by onboard microcomputers 
and, for SAMPEX, is only output on receipt of a command. It was only included in the 
SAMPEX study since it is the only source of instrument housekeeping data available in the 
control center. These data packets consist of a one orbit sample of various instrument rate 
counters and housekeeping status. 


Data Processing Functions for Data Analysis and Performance Trending 

The data processing functions done for data analysis and performance trending are 
very similar to the data processing steps for science data analysis. The first step involves a 
quality and accounting assessment to ensure that an adequate amount of data is recovered for 
data analysis and performance trending. The raw data is generally archived to provide a 
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backup in the event a data processing error is discovered in the future. Optional data merging 
may be done to combine real-time and playback data or to replace bad quality data with a § g 
bettei, retransmitted value. Finally, the data can be sorted by function or subsystem. 

k T ? e T Xt Step ge T rally Evolves ingesting the data values and affixed time-tags into a 
database for later access by analysis tools. This step includes processing the data and 
monitoring for high and low limit violations, verifying configuration and discrete state checks 
and optionally perfomiing engineering unit conversions (if the storage IS dTnrt 
provide this function). At this point the data may also be processed to provide 
maximum/mean/mimmum values of analog values for long term performance trending This 
ata may be processed for single orbits, daily or some other periodic unit of time. 

_ , . After the data has been processed and stored in an on-line database, routine data 
analysis can be performed. This routine analysis function can generally be automated and mav 
include creation of x/y plots for the thermal, communications or poKbs wdl 

conttol 5Udget m ° nit0ring ^ analysiS ° r f0r attitude determination and 

Finally some sort of orbit propagation may be done to provide a definitive history of 
actual spacecraft position over time. This data can be used both in subsequent anomaly 
investigation or for long term performance trending and is generally needed to isolate 
spacecraft problems that may be due to an environmental factor. In most circumstances, orbit 
accuracy requnements for science data processing are tighter than that required for 
performance analysis and therefore a commercial off the shelf orbit propagator, or ephemeri 

f ienCe da f analysis ’ is sufflcient ‘ This data must be stored, or made 
available, to any plotting packages that would have access to the on-line spacecraft database 
and be used for analysis and trending. F udiauase 

Special data processing may then be required to further analyze any spacecraft 
( a "® a iCS ' A S0, short and long term trending may be done. Short term trending may involve 
ompanng a sample orbit signature of a telemetry point with a comparable earlier orbit 
mfn a tUie 1 ? omtor for degradation or orbit patterns. Long term trending may involve such 
things as plotting minimum, mean and maximum values of telemetry points (1 point per orbit 

° r tk y ’ C ^ C ' -° Ver ? 0nger time s P an t0 m enitor seasonal or longer term trends Long term 
earth projection plots may be used to monitor single event upsets or other environmental 
errects on spacecraft performance. 


Onboard packetization strategies 

For the data that is only of interest when it changes, such as command execution 
counters, command execution error counters, other error counters and digital status data 
onboard storage space could be saved if this data were stored only when something changes 
Depending on how many telemetry points fall into this category, one or two packet formats * 
(more if large amounts of these points exist or if separation by subsystem is desired) should 
k s P^ c ft ied - To save storage space if there are more than a few of these points, two packets 
should be defined separating data that is expected to periodically change and data that should 
never, or very rarely, change. 

This data could then be sampled synchronously onboard, formatted into a packet and 
compared to the previous sample. If the comparison showed a difference, the old and new for 
just the new) packets could be stored. Else, the old packet could be discarded and the new 
packet saved for comparison with the next sample. The sampling rate should be frequent 
enough to provide the time of the change to within a few seconds and should also be frequent 
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enough to catch every state transition. If a relay can be powered on and back off between 
samples, the ground operations team may never know that a transition occurred. If there is a 
concern of scheduling reads to quickly, the individual subsystem could maintain a history of 
the last few settings of the discrete and the associated times or just keep track of all transitions 
between readings and set a flag if more than one transition occurred since the last sampling. 

Finally, this data could also always come down in real-time, if there is enough down 
link bandwidth, or could be stored or down linked on command. This would provide the 
ground operations team a sanity check on the data to ensure that a change does not go 
undetected due to a lost packet. Another possibility , is to treat some or all of these items as 
spacecraft events and issue an event message containing the telemetry mnemonic, the previous 
and current values and the time of the transition rather than store the full data packet that 
contains a sampling of all of the discrete, infrequently changing values. The configuration and 
counter packet(s) could then be available for storage or real-time down link on command in 
order to provide sanity checks. 

The next type of data is the frequently or constantly changing data. This category 
includes analog data, flight software task execution counters and data storage accounting 
statistics. Analog data, when synchronously stored, is generally compromised. By this, I 
mean that this data is usually stored at a rate that is to frequent when the spacecraft health is 
nominal and not frequent enough for analysis purposes when there is a spacecraft anomaly to 
investigate. 

One way to improve upon this is to take advantage of current flight certified onboard 
computer capabilities (usually required to take full advantage of the CCSDS protocol anyway) 
to move analog and discrete monitoring functions (limit, state and configuration checking) 
from the ground data system to the spacecraft. This would give the spacecraft the ability to 
detect its own anomalies, take immediate command response to anticipated contingencies and 
provide higher resolution data for use in ground analysis when a discrepancy occurs. Analog 
data could be stored in a circular buffer onboard the spacecraft. This buffer would be sized to 
hold approximately one orbit, or other suitable time increment, of high resolution analog data. 
If a monitor violation is detected by the onboard computer, then the contents of the circular 
buffer, or an appropriate subset of that data, can be transferred to the data storage recorder for 
subsequent ground data analysis of the problem. During the rest of the time, this data could 
be filtered before being recorded such that enough data is always available to do performance 
trending, but higher resolution data is available for anomaly analysis. By allowing this 
circular buffer to be stored or down linked on command, daily high resolution or "typical 
orbit" plots could be maintained. Filtered data would then fill in the rest of the day. 

With a more sophisticated onboard computer, the function of calculating and saving 
the maximum, minimum and mean values for a given telemetry point, on a per orbit or other 
incremental period, could also be migrated to the spacecraft. This could be particularly useful 
for power system analysis, where it is often desired to identify when a current or voltage spike 
may have occurred. Currently this is like looking for a needle in a haystack as the 
synchronous data sampling either results in the spike not being recorded or in the inability to 
determine exactly how long the event actually occurred. By combining min./mean/max. data 
with high resolution data output when a monitor is violated, work on detecting, monitoring 
and isolating power spikes could be greatly enhanced. Also, min./mean/max. data could give 
a good, quick view of the spacecraft thermal performance. 

If the min. /mean/ max. data was sampled directly from the analog source, or the high 
resolution buffer, a better data set could be obtained onboard than could be calculated on the 
ground from the lower resolution, filtered data that would be stored onboard when spacecraft 
functions were nominal. This would result in better long term trending data. 
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exZrS&°“ taS u l0adln / 0r t0 diagnose a new flight software patch For 
sisSanri v Hif^ PE ^ W 5 attem P ted t0 see lf flight software tasks were running at a 
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increase packet size is to specify packet contents based on output frequency rather than hv 
ource. This allows fewer, larger packet types to be managed by JL 

Oto ,K„ comh™, d,» P,ck« if p«,He, „„ Other inJKXSSSSJXu,. 


Implications to spacecraft data storage sizing 

Since many of the proposals in this paper suggest event driven rather than 

r“S^ 

Therefore it is recommended that housekeeping storage space be sized to hnlrl thp 
expected amount of housekeeping data under nominal conditions, allowing for anv additional 

to alIow r, or more down ^ 

particular data dump. Then some space could be reallocated from the science allotment If 
needed, in order to store higher packet output rates generated when spacecraft algorithm's 
explained above increase the amount of housekeeping data saved. By sharing some science 
orage allocation, science data output can be maximized when spacecraft operation is 
nominal. This shared area could then be reallocated to 

problems cause higher packet output rates to be needed. It may even be possible to set this un 
in a way that less valuable science data would be lost in the event of a problem Even though^ 
this could result in periodic losses of some of the science data, it shodd^mo^S^, 
ccorded during nominal periods when the housekeeping data output is reduced to a 
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minimum and could allow for more expedient detection and correction of small problems 
before they become big problems. 


Summary 

By taking advantage of the event driven nature of the CCSDS protocol and by 
migrating some of the basis data checks from the ground to the spacecraft, the output of 
spacecraft housekeeping data can be optimized to provide a more prudent balance with science 
data. By monitoring discrete telemetry, only information on state transitions or counter 
increments need be transmitted to the ground rather than synchronous output of redundant 
data. On command discrete telemetry packets can provide the ground with a sanity check. 
Also, by having the spacecraft monitor analog limits and subsystem configurations, analog 
data output can be throttled to provide increased data output rates when potential problems 
exist while filtering this output during nominal operations. By having the spacecraft calculate 
max./mean/min. data, long term trending of spacecraft performance can be greatly enhanced. 
Finally, by sharing recorder overflow space with science, optimum science output can be 
achieved when spacecraft performance is nominal and finer resolution housekeeping data can 
be output when there is an indication of a performance problem. 
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